Crate rustls

source ·
Expand description

§Rustls - a modern TLS library

Rustls is a TLS library that aims to provide a good level of cryptographic security, requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography by default.

§Current functionality (with default crate features)

  • TLS1.2 and TLS1.3.
  • ECDSA, Ed25519 or RSA server authentication by clients.
  • ECDSA, Ed25519 or RSA server authentication by servers.
  • Forward secrecy using ECDHE; with curve25519, nistp256 or nistp384 curves.
  • AES128-GCM and AES256-GCM bulk encryption, with safe nonces.
  • ChaCha20-Poly1305 bulk encryption (RFC7905).
  • ALPN support.
  • SNI support.
  • Tunable fragment size to make TLS messages match size of underlying transport.
  • Optional use of vectored IO to minimise system calls.
  • TLS1.2 session resumption.
  • TLS1.2 resumption via tickets (RFC5077).
  • TLS1.3 resumption via tickets or session storage.
  • TLS1.3 0-RTT data for clients.
  • TLS1.3 0-RTT data for servers.
  • Client authentication by clients.
  • Client authentication by servers.
  • Extended master secret support (RFC7627).
  • Exporters (RFC5705).
  • OCSP stapling by servers.

§Non-features

For reasons explained in the manual, rustls does not and will not support:

  • SSL1, SSL2, SSL3, TLS1 or TLS1.1.
  • RC4.
  • DES or triple DES.
  • EXPORT ciphersuites.
  • MAC-then-encrypt ciphersuites.
  • Ciphersuites without forward secrecy.
  • Renegotiation.
  • Kerberos.
  • TLS 1.2 protocol compression.
  • Discrete-log Diffie-Hellman.
  • Automatic protocol version downgrade.
  • Using CA certificates directly to authenticate a server/client (often called “self-signed certificates”). Rustls’ default certificate verifier does not support using a trust anchor as both a CA certificate and an end-entity certificate in order to limit complexity and risk in path building. While dangerous, all authentication can be turned off if required – see the example code.

There are plenty of other libraries that provide these features should you need them.

§Platform support

While Rustls itself is platform independent, by default it uses ring for implementing the cryptography in TLS. As a result, rustls only runs on platforms supported by ring. At the time of writing, this means 32-bit ARM, Aarch64 (64-bit ARM), x86, x86-64, LoongArch64, 32-bit & 64-bit Little Endian MIPS, 32-bit PowerPC (Big Endian), 64-bit PowerPC (Big and Little Endian), 64-bit RISC-V, and s390x. We do not presently support WebAssembly. For more information, see the supported ring target platforms.

By providing a custom instance of the crypto::CryptoProvider struct, you can replace all cryptography dependencies of rustls. This is a route to being portable to a wider set of architectures and environments, or compliance requirements. See the crypto::CryptoProvider documentation for more details.

Specifying default-features = false when depending on rustls will remove the dependency on ring.

Rustls requires Rust 1.61 or later.

§Design Overview

§Rustls does not take care of network IO

It doesn’t make or accept TCP connections, or do DNS, or read or write files.

There’s example client and server code which uses mio to do all needed network IO.

§Rustls provides encrypted pipes

These are the ServerConnection and ClientConnection types. You supply raw TLS traffic on the left (via the read_tls() and write_tls() methods) and then read/write the plaintext on the right:

         TLS                                   Plaintext
         ===                                   =========
    read_tls()      +-----------------------+      reader() as io::Read
                    |                       |
          +--------->   ClientConnection    +--------->
                    |          or           |
          <---------+   ServerConnection    <---------+
                    |                       |
    write_tls()     +-----------------------+      writer() as io::Write

§Rustls takes care of server certificate verification

You do not need to provide anything other than a set of root certificates to trust. Certificate verification cannot be turned off or disabled in the main API.

§Getting started

This is the minimum you need to do to make a TLS client connection.

First we load some root certificates. These are used to authenticate the server. The simplest way is to depend on the webpki_roots crate which contains the Mozilla set of root certificates.

let mut root_store = rustls::RootCertStore::empty();
root_store.extend(
    webpki_roots::TLS_SERVER_ROOTS
        .iter()
        .cloned()
);

Next, we make a ClientConfig. You’re likely to make one of these per process, and use it for all connections made by that process.

let config = rustls::ClientConfig::builder()
    .with_root_certificates(root_store)
    .with_no_client_auth();

Now we can make a connection. You need to provide the server’s hostname so we know what to expect to find in the server’s certificate.

let rc_config = Arc::new(config);
let example_com = "example.com".try_into().unwrap();
let mut client = rustls::ClientConnection::new(rc_config, example_com);

Now you should do appropriate IO for the client object. If client.wants_read() yields true, you should call client.read_tls() when the underlying connection has data. Likewise, if client.wants_write() yields true, you should call client.write_tls() when the underlying connection is able to send data. You should continue doing this as long as the connection is valid.

The return types of read_tls() and write_tls() only tell you if the IO worked. No parsing or processing of the TLS messages is done. After each read_tls() you should therefore call client.process_new_packets() which parses and processes the messages. Any error returned from process_new_packets is fatal to the connection, and will tell you why. For example, if the server’s certificate is expired process_new_packets will return Err(InvalidCertificate(Expired)). From this point on, process_new_packets will not do any new work and will return that error continually.

You can extract newly received data by calling client.reader() (which implements the io::Read trait). You can send data to the peer by calling client.writer() (which implements io::Write trait). Note that client.writer().write() buffers data you send if the TLS connection is not yet established: this is useful for writing (say) a HTTP request, but this is buffered so avoid large amounts of data.

The following code uses a fictional socket IO API for illustration, and does not handle errors.

use std::io;
use rustls::Connection;

client.writer().write(b"GET / HTTP/1.0\r\n\r\n").unwrap();
let mut socket = connect("example.com", 443);
loop {
  if client.wants_read() && socket.ready_for_read() {
    client.read_tls(&mut socket).unwrap();
    client.process_new_packets().unwrap();

    let mut plaintext = Vec::new();
    client.reader().read_to_end(&mut plaintext).unwrap();
    io::stdout().write(&plaintext).unwrap();
  }

  if client.wants_write() && socket.ready_for_write() {
    client.write_tls(&mut socket).unwrap();
  }

  socket.wait_for_something_to_happen();
}

§Examples

tlsserver-mio and tlsclient-mio are full worked examples using mio.

§Crate features

Here’s a list of what features are exposed by the rustls crate and what they mean.

  • ring (enabled by default): makes the rustls crate depend on the ring crate, which is used for cryptography by default. Without this feature, these items must be provided externally to the core rustls crate: see CryptoProvider.

  • aws_lc_rs: makes the rustls crate depend on the aws-lc-rs crate, which can be used for cryptography as an alternative to ring. Use rustls::crypto::aws_lc_rs::default_provider() as a CryptoProvider when making a ClientConfig or ServerConfig to use aws-lc-rs

    Note that aws-lc-rs has additional build-time dependencies like cmake. See the documentation for details.

  • tls12 (enabled by default): enable support for TLS version 1.2. Note that, due to the additive nature of Cargo features and because it is enabled by default, other crates in your dependency graph could re-enable it for your application. If you want to disable TLS 1.2 for security reasons, consider explicitly enabling TLS 1.3 only in the config builder API.

  • logging (enabled by default): make the rustls crate depend on the log crate. rustls outputs interesting protocol-level messages at trace! and debug! level, and protocol-level errors at warn! and error! level. The log messages do not contain secret key data, and so are safe to archive without affecting session security.

  • read_buf: when building with Rust Nightly, adds support for the unstable std::io::ReadBuf and related APIs. This reduces costs from initializing buffers. Will do nothing on non-Nightly releases.

Re-exports§

Modules§

  • client
    Items for use in a client.
  • crypto
    Crypto provider interface.
  • internal
    Internal classes that are used in integration tests. The contents of this section DO NOT form part of the stable interface.
  • manual
    This is the rustls manual.
  • pki_types
    Re-exports the contents of the rustls-pki-types crate for easy access
  • quic
    APIs for implementing QUIC TLS
  • server
    Items for use in a server.
  • sign
    Message signing interfaces.
  • ticketer
    APIs for implementing TLS tickets
  • version
    All defined protocol versions appear in this module.

Structs§

Enums§

  • AlertDescription
    The AlertDescription TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • CertRevocationListError
    The ways in which a certificate revocation list (CRL) can be invalid.
  • CertificateError
    The ways in which certificate validators can express errors.
  • CipherSuite
    The CipherSuite TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • Connection
    A client or server connection.
  • ConnectionTrafficSecrets
    Secrets used to encrypt/decrypt data in a TLS session.
  • ContentType
    The ContentType TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • Error
    rustls reports protocol errors using this type.
  • HandshakeType
    The HandshakeType TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • InvalidMessage
    A corrupt TLS message payload that resulted in an error.
  • NamedGroup
    The NamedGroup TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • PeerIncompatible
    The set of cases where we failed to make a connection because a peer doesn’t support a TLS version/feature we require.
  • PeerMisbehaved
    The set of cases where we failed to make a connection because we thought the peer was misbehaving.
  • ProtocolVersion
    The ProtocolVersion TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • Side
    Side of the connection.
  • SignatureAlgorithm
    The SignatureAlgorithm TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • SignatureScheme
    The SignatureScheme TLS protocol enum. Values in this enum are taken from the various RFCs covering TLS, and are listed by IANA. The Unknown item is used when processing unrecognised ordinals.
  • SupportedCipherSuite
    A cipher suite supported by rustls.

Statics§

  • ALL_VERSIONS
    A list of all the protocol versions supported by rustls.
  • DEFAULT_VERSIONS
    The version configuration that an application should use by default.

Traits§